System and method for creating multiple versions of a descriptor file

ABSTRACT

A system (e.g., content management system, content delivery system) and method are described herein which are configured for receiving one or more source descriptor files (e.g., MPD files, HLS m3u8 files, HTTP manifest files) along with associated adaptive bit rate segments. The system and method are also configured for receiving rules (e.g., content ratings, timing information, user profiles, regional and demographic information) and then creating multiple descriptor files based on the received rules and the source descriptor file(s). The system and method are further configured for distributing the multiple descriptor files to one or more downstream systems (e.g., content to delivery systems, users).

TECHNICAL FIELD

The present invention relates to system (e.g., content managementsystem, content delivery system) and method configured for receiving oneor more source descriptor files (e.g., MPD files, HLS m3u8 files, HTTPmanifest files) along with associated adaptive bit rate segments. Thesystem and method are also configured for receiving rules (e.g., contentratings, timing information, user profiles, regional and demographicinformation) and then creating multiple descriptor files based on thereceived rules and the source descriptor file(s). The system and methodare further configured for distributing the multiple descriptor files toone or more downstream systems (e.g., content delivery systems, users).

BACKGROUND

The following abbreviations herewith defined are referred to within thefollowing description about the prior art and the present invention.

DASH Dynamic Adaptive Streaming over HTTP

HLS HTTP Live Streaming HTTP Hypertext Transfer Protocol MPD MediaPresentation Description MPEG Moving Picture Experts Group

DASH is a multimedia adaptive bit rate streaming technology where amultimedia content file (e.g., video, television, radio . . . ) ispartitioned into segments and delivered to a client using HTTP. Inparticular, the multimedia content file is split into multiple segmentsand these segments are linked together by a MPD file which is sent tothe client. The client uses the MPD file to request the segments of themultimedia content file. The MPD file contains information (timing, URL,media characteristics such as video resolution and bit rates) related tothe one or more segments. Each segment can contain any type of mediadata, however the DASH specification provides specific guidance andformats for two types of containers namely the MPEG-4 file format or theMPEG-2 Transport Stream format. Furthermore, DASH is audio/video codecagnostic. Hence, one or more representations (i.e., differentresolutions or bit rates) of the multimedia content file is typicallyavailable, and the selection of which multimedia content file'srepresentation that is to be sent to the client can be made based onvarious factors such as the network conditions, the client's devicecapabilities, and the user preferences.

In the existing business process/technology, if a content managementsystem (or content delivery system) wants to create multiple versions ofthe same multimedia content file (e.g., adult & non-adult versions,multiple language versions, subscription type version (standard vs.premium subscription)), then multiple content files with relevantaudio/video tracks which are properly cut based on timings, need to becreated. Since multiple content files are created from one mastermultimedia content file, it can be complicated for the contentmanagement system (or content delivery system) to maintain and trackthese different versions of the master multimedia content file. Plus,the storage requirements for the content management system (or contentdelivery system) can increase based on the number of versions of themaster multimedia content file which need to be stored. In addition, thecontent management system (or content delivery system) needs to spendthe time to create the new versions of the master multimedia contentfile. Accordingly, there has been and is a need to address theseshortcomings and other shortcomings associated with the currentmultimedia adaptive bit rate streaming technology. This need and otherneeds are addressed by the present invention.

SUMMARY

A system and method which addresses several needs associated with thecurrent multimedia adaptive bit rate streaming technology have beendescribed in the independent claims of the present application.Advantageous embodiments of the system and method have been described inthe dependent claims of the present application.

In one aspect, the present invention provides a system configured tocreate multiple descriptor files. The system comprises a processor and amemory that stores processor-executable instructions therein where theprocessor interfaces with the memory and executes theprocessor-executable instructions to enable following operations: (1)receiving one or more source descriptor files and associated adaptivebit rate segments for one or more master content files; (2) receivingrules which provide details on how the multiple descriptor files are tobe created; (3) creating the multiple descriptor files based on therules and the one and more source descriptor files; and (4) distributingone or more of the multiple descriptor files to one or more downstreamsystems. The system has an advantage in that by creating multipledescriptor files it avoids having to create multiple versions of the oneor more master content files which saves time and reduces maintenanceand storage costs.

In yet another aspect, the present invention provides a method forcreating multiple descriptor files. The method is implemented by asystem and comprises the steps of: (1) (1) receiving one or more sourcedescriptor files and associated adaptive bit rate segments for one ormore master content files; (2) receiving rules which provide details onhow the multiple descriptor files are to be created; (3) creating themultiple descriptor files based on the rules and the one and more sourcedescriptor files; and (4) distributing one or more of the multipledescriptor files to one or more downstream systems. The method has anadvantage in that by creating multiple descriptor files it avoids havingto create multiple versions of the one or more master content fileswhich saves time and reduces maintenance and storage costs.

Additional aspects of the invention will be set forth, in part, in thedetailed description, figures and any claims which follow, and in partwill be derived from the detailed description, or can be learned bypractice of the invention. It is to be understood that both theforegoing general description and the following detailed description areexemplary and explanatory only and are not restrictive of the inventionas disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be obtainedby reference to the following detailed description when taken inconjunction with the accompanying drawings:

FIG. 1A is a diagram of an exemplary system (e.g., content managementsystem, content delivery system) configured for creating multipledescriptor files in accordance with an embodiment of the presentinvention;

FIG. 1B is a diagram of an exemplary source descriptor file which isconfigured per the DASH standard and is known to those skilled in theart as a media presentation description (MPD) file;

FIG. 2A is a flowchart of an exemplary method which is implemented bythe system shown in FIG. 1A for creating multiple descriptor files inaccordance with an embodiment of the present invention;

FIG. 2B is a flowchart illustrating in greater detail the stepsassociated with the creating step of the method shown in FIG. 2A inaccordance with an embodiment of the present invention;

FIGS. 3A-3D are several diagrams associated with an exemplary contentmanagement system which are used to explain a use case #1 in accordancewith an embodiment of the present invention;

FIGS. 4A-4H are several diagrams associated with an exemplary contentmanagement system which are used to explain a use case #2 in accordancewith an embodiment of the present invention;

FIG. 5 is a diagram an exemplary content delivery system which is usedto explain a use case #3 in accordance with an embodiment of the presentinvention; and

FIGS. 6A-6B are diagrams of an exemplary content delivery system whichis used to explain a use case #4 in accordance with an embodiment of thepresent invention.

DETAILED DESCRIPTION

Referring to FIG. 1A, there is shown a diagram of an exemplary system100 configured in accordance with an embodiment of the presentinvention. As shown, the system 100 (e.g., content management system100′, content delivery system 100″) includes an input interface 104, aprocessor 106, a memory 108, a database 111, and an output interface112. The system 100 may include many other components which are wellknown in the art but for clarity those well known components are notdescribed herein. In this example, the system's input interface 104 isconfigured to interface with one or more remote transcoders 114 ₁, 114 ₂. . . 114 _(n) and receive therefrom one or more source descriptor files116 ₁, 116 ₂ . . . 116 _(n) (e.g., MPD files, HLS m3u8 files, HTTPmanifest files) and their associated adaptive bit rate segments 118 ₁,118 ₂ . . . 118 _(n) (see step 1). As shown, the remote transcoders 114₁, 114 ₂ . . . 114 _(n) respectively receive the master content files120 ₁, 120 ₂ . . . 120 _(n) and produce the corresponding sourcedescriptor files 116 ₁, 116 ₂ . . . 116 _(n) and their associatedadaptive bit rate segments 118 ₁, 118 ₂ . . . 118 _(n). An exemplarysource descriptor file 116 ₁ which is configured per the DASH standardis described next with respect to FIG. 1B.

Referring to FIG. 1B, there is a diagram of an exemplary sourcedescriptor file 116 ₁ which is configured per the DASH standard and isknown to those skilled in the art as a MPD file 116 ₁. The exemplary MPDfile 116 ₁ is a layered structure which includes a media presentation122 which has multiple periods 124 ₁, 124 ₂, 124 ₃ . . . 124 _(n). Theperiods 124 ₁, 124 ₂, 124 ₃ . . . 124 _(n) are spliced together intospecific time periods and contain information about arbitrary content(e.g., URL's to the adaptive bit rate segments 118 ₁, 118 ₂ . . . 118_(n)). Each period 124 ₁ (for example) has URL information 126 and oneor more adaptation sets 128 ₁, 128 ₂ . . . 128 _(n) which indicate aselection of components/tracks. Each adaptation set 1 128 ₁ (forexample) includes one or more representations 130 ₁, 130 ₂ . . . 130_(n) each of which contains information about different bandwidths 132₁, 132 ₂ . . . 132 _(n) and associated formats 134 ₁, 134 ₂ . . . 134_(n) for various segments 136 ₁, 136 ₂ . . . 136 _(n). Eachrepresentation 130 ₁ (for example) contains initialization segmentinformation 138 and multiple media segments 140 ₁, 140 ₂, 140 ₃ . . .140 _(n) each of which contains timing information and a URL. Asdiscussed in detail below, the system 100 is configured to exploit thelayered structure of the MPD file 116 ₁ (or multiple MPD files 116 ₂ . .. 116 _(n)) in a unique manner to obtain different MPD files 142 ₁, 142₂ . . . 142 _(n) rather than have to create different media contentfiles as was needed in the state-of-the-art whenever one wanted multipleversions of the same multimedia content file (e.g., adult & non-adultversions, multiple language versions, subscription type version(standard vs. premium subscription)),

To accomplish this, the system's processor 106 interacts with the memory108 which stores processor-executable instructions and executes theprocessor-executable instructions to enable the following operations:(1) receive the one or more source descriptor files 116 ₁, 116 ₂ . . .116 _(n) and their associated adaptive bit rate segments 118 ₁, 118 ₂ .. . 118 _(n) for one or more master content files 120 ₁, 120 ₂ . . . 120_(n) (FIG. 1A's step 1); (2) receive rules 144 which provide details onhow the multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n) are to becreated (FIG. 1A's step 2) (note: an operator 146 can provide the rules144); (3) create the multiple descriptor files 142 ₁, 142 ₂ . . . 142_(n) based on the rules 144 and the one and more source descriptor files116 ₁, 116 ₂ . . . 116 _(n) (FIG. 1A's step 3); and (4) distribute oneor more of the multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n) toone or more downstream systems 148 ₁, 148 ₂ . . . 148 _(n) (FIG. 1A'sstep 4). A more detailed discussion about this process including severaladditional features related to creating the multiple descriptor files142 ₁, 142 ₂ . . . 142 _(n) is provided below with respect to a method200 shown in FIGS. 2A-2B and to exemplary use cases 1-4 shown in FIGS.3-6.

Referring to FIG. 2A, there is a flowchart of an exemplary method 200which is implemented by the system 100 for creating multiple descriptorfiles 142 ₁, 142 ₂ . . . 142 _(n) in accordance with an embodiment ofthe present invention. At step 202, the system 100 receives the one ormore source descriptor files 116 ₁, 116 ₂ . . . 116 _(n) and theirassociated adaptive bit rate segments 118 ₁, 118 ₂ . . . 118 _(n) forone or more master content files 120 ₁, 120 ₂ . . . 120 _(n). Forinstance, the source descriptor file(s) 116 ₁, 116 ₂ . . . 116 _(n) maybe configured as MPD files, HLS m3u8 files, or HTTP manifest filesdepending on the particular streaming technology used by the transoders114 ₁, 114 ₂ . . . 114 _(n). At step 204, the system 100 receives rules144 which provide details on how the multiple descriptor files 142 ₁,142 ₂ . . . 142 _(n) are to be created. The operator 146 can provide therules 144 which include a wide variety of information/criteria thatdictates how to create the multiple descriptor files 142 ₁, 142 ₂ . . .142 _(n). For instance, the rules 144 can include information/criteriarelated to content ratings, language information, timing information,metadata, user profiles, and regional and demographic information. Atstep 206, the system 100 creates the multiple descriptor files 142 ₁,142 ₂ . . . 142 _(n) based on the rules 144 and the one and more sourcedescriptor files 116 ₁, 116 ₂ . . . 116 _(n) and associated adaptive bitrate segments 118 ₁, 118 ₂ . . . 118 _(n) (see FIG. 2B for a moredetailed discussion about different features of the creating step 206).At step 208, the system 100 distributes the one or more of the multipledescriptor files 142 ₁, 142 ₂ . . . 142 _(n) to one or more downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n). If the system 100 does not send allof the of the multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n) toeach downstream systems 148 ₁, 148 ₂ . . . 148 _(n), then the system 100would utilize a resolve mechanism 145 to determine which of the multipledescriptor files 142 ₁, 142 ₂ . . . 142 _(n) to send to each downstreamsystem 148 ₁, 148 ₂ . . . 148 _(n) (see FIGS. 5-6 for more detaileddiscussion).

Referring to FIG. 2B, there is a flowchart illustrating in greaterdetail several exemplary steps associated with the creating step 206shown in FIG. 2A in accordance with an embodiment of the presentinvention. As described above, the system 100 creates the multipledescriptor files 142 ₁, 142 ₂ . . . 142 _(n) based on the rules 144 andthe one and more source descriptor files 116 ₁, 116 ₂ . . . 116 _(n) andassociated adaptive bit rate segments 118 ₁, 118 ₂ . . . 118 _(n). Toaccomplish this, the system 100 at step 210 manipulates one or more ofthe source descriptor files 116 ₁, 116 ₂ . . . 116 _(n) based on therules 144 without transcoding the source descriptor files 116 ₁, 116 ₂ .. . 116 _(n) to an adaptive stream format and without generating newcontent files to create the multiple descriptor files 142 ₁, 142 ₂ . . .142 _(n). The system 100 can manipulate one or more of the sourcedescriptor files 116 ₁, 116 ₂ . . . 116 _(n) in a wide-variety of waysto create the multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n)several exemplary ways are as follows:

-   -   The system 100 at step 210 a can remove at least one period 124        ₁, 124 ₂ . . . 124 _(n) including a video track and an audio        track from one of the source descriptor files 116 ₁, 116 ₂ . . .        116 _(n) and recode the timing information within the one source        descriptor file 116 ₁, 116 ₂ . . . 116 _(n) to create one of the        multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n) (see use        cases 1 and 3).    -   The system 100 at step 210 b can remove an audio track from one        of the source descriptor files 116 ₁, 116 ₂ . . . 116 _(n) to        create one of the multiple descriptor files 142 ₁, 142 ₂ . . .        142 _(n) (see use cases 1 and 3).    -   The system 100 at step 210 c can add advertisements from one or        more of the source descriptor files 116 ₁, 116 ₂ . . . 116 _(n)        to another one of the source descriptor files 116 ₁, 116 ₂ . . .        116 _(n) to create one of the multiple descriptor files 142 ₁,        142 ₂ . . . 142 _(n) (see use cases 2 and 4).    -   The system 100 at step 210 d can add one or more periods 124 ₁,        124 ₂ . . . 124 _(n) each including a video track and an audio        track from one of source descriptor files 116 ₁, 116 ₂ . . . 116        _(n) to one of the other source files 116 ₁, 116 ₂ . . . 116        _(n) to create one of the multiple descriptor files 142 ₁, 142 ₂        . . . 142 _(n) (see use cases 2 and 4).    -   The system 100 at step 210 e can add one or more audio tracks        from one or more of the source descriptor files 116 ₁, 116 ₂ . .        . 116 _(n) to one of the other source files 116 ₁, 116 ₂ . . .        116 _(n) to create one of the multiple descriptor files 142 ₁,        142 ₂ . . . 142 _(n) (see use cases 2 and 4).

Referring to FIGS. 3A-3D, there are several diagrams associated with anexemplary content management system 100′ which are used to explain a usecase #1 in accordance with an embodiment of the present invention. Asshown in FIG. 3A, the content management system 100′ includes the inputinterface 104, the processor 106, the memory 108, the database 1111, andthe output interface 112. In this particular example, the system's inputinterface 104 is shown interfacing with one remote transcoder 114 ₁ andreceiving therefrom one source descriptor file 116 ₁ (MPD file 116 ₁)and the associated adaptive bit rate segments 118 ₁. The remotetranscoder 114 ₁ receives the master content file 120 ₁ and produces thecorresponding source descriptor file 116 ₁ and the associated adaptivebit rate segments 118 ₁. The basic steps associated with the use case #1are as follows:

-   -   1. The MPEG-DASH transcoder 114 ₁ provides the MPD file 116 ₁        and the adaptive bit rate segments 118 ₁ for the master content        file 120 ₁.    -   2. The MPEG-DASH transcoder's 114 ₁ output namely the MPD file        116 ₁ and the adaptive bit rate segments 118 ₁ are received by        the content management system 100′. Note: The MPD file 116 ₁ and        the adaptive bit rate segments 118 ₁ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₁.    -   3. The user 146 creates rules 144 which provide details on how        to create the multiple versions of MPD files 142 ₁, 142 ₂ . . .        142 _(n). The rules 144 can be and not limited to, based on        timing information, metadata, user profiles, content ratings,        regional and demographic information etc.    -   4. The processor 106-memory 108 (e.g., rules engine) uses the        rules 144, the MPD file 116 ₁ and the adaptive bit rate segments        118 ₁ to create the multiple versions of MPD files 142 ₁, 142 ₂        . . . 142 _(n).        -   An example is discussed next to help explain several ways            that the processor 106-memory 108 (e.g., rules engine) can            use the rules 144 and the MPD file 116 ₁ to create the            multiple versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n).            In this example, FIG. 3B illustrates a portion of the MPD            file 116 ₁ (e.g., master MPD file 116 ₁) which has a media            presentation 122 with multiple periods 124 ₁, 124 ₂, 124 ₃,            124 ₄ and the first period 124 ₁ includes adaptation sets            128 ₁, 128 ₂, 128 ₃, 128 ₄. FIG. 3C illustrates a portion of            the “version 1” MPD file 142 ₁ which was created by the            processor 106-memory 108 (e.g., rules engine) when using the            rule 144 which is set to remove the period 124 ₂ with time            codes 100s to 199s from the MPD file 116 ₁ and to recode the            time in the newly created “version 1” MPD file 142 ₁. The            “version 1” MPD file 142 ₁ includes a media presentation 122            with multiple periods 124 ₁, 124 ₃, 124 ₄ where new time            codes 100s and 200s are associated with periods 124 ₃ and            124 ₄. FIG. 3D illustrates a portion of the “version 2” MPD            file 142 ₂ which was created by the processor 106-memory 108            (e.g., rules engine) when using the rule 144 which is set to            remove audio track 3. The “version 2” MPD file 142 ₂ include            a media presentation 122 with multiple periods 124 ₁, 124 ₂,            124 ₃, 124 ₄ and the first period 124 ₁ now includes            adaptation sets 128 ₁, 128 ₂, 128 ₃, and no longer includes            adaptation set 128 ₄ (note: the other periods 124 ₂, 124 ₃,            124 ₄ no longer include adaptation set 128 ₄).    -   5. The processor 106-memory 108 then distributes the different        versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n) to        corresponding downstream systems 148 ₁, 148 ₂ . . . 148 _(n)        (e.g., content delivery networks 148 ₁, 148 ₂ . . . 148 _(n))        based on requirements.

Note 1: In FIG. 3A, versioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) arepresented as output of the processor 106-memory 108 (e.g., rule engine).In this case, the processor 106-memory 108 (e.g., rule engine)dynamically generates the versioned MPD files 142 ₁, 142 ₂ . . . 142_(n) on the fly and distributes them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n). Alternatively, the processor106-memory 108 (e.g., rule engine) can generate and store (cache) theversioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) in the database 111 andthen at some later time distribute them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n).

Note 2: The exemplary system 100′ may include many other well knowncomponents but for clarity those well known components are not describedherein while the components 104, 106, 108, 111 and 112 which arerelevant to the invention have been described.

Note 3: The use case #1 included an example utilizing the DASH standardbut it should be appreciated that the present invention is not limitedto the DASH standard but could utilize other adaptive streamingtechnologies such as HLS by Apple, Smooth Streaming by Microsoft, or HDSby Adobe.

Referring to FIGS. 4A-4H, there are several diagrams associated with anexemplary content management system 100′ which are used to explain a usecase #2 in accordance with an embodiment of the present invention. Asshown in FIGS. 4A1 and 4A2, the content management system 100′ includesthe input interface 104, the processor 106, the memory 108, the database111, and the output interface 112. In this particular example, thesystem's input interface 104 is shown interfacing with four remotetranscoders 114 ₁, 114 ₂, 114 ₃, 114 ₄ and respectively receivingtherefrom three source descriptor files 116 ₁, 116 ₂, 116 ₃, 116 ₄(e.g., MPD files) and their associated adaptive bit rate segments 118 ₁,118 ₂, 118 ₃, 118 ₄. As shown, the remote transcoders 114 ₁, 114 ₂, 114₃, 114 ₄ respectively receive the master content files 120 ₁, 120 ₂, 120₃, 120 ₄ and produce the corresponding source descriptor files 116 ₁,116 ₂, 116 ₃, 116 ₄ and their associated adaptive bit rate segments 118₁, 118 ₂, 118 ₃, 118 ₄. The basic steps associated with the use case #2are as follows:

-   -   1. The MPEG-DASH transcoder 114 ₁ provides the MPD file 116 ₁        and the adaptive bit rate segments 118 ₁ for the master content        file 120 ₁.    -   2. The MPEG-DASH transcoder's 114 ₁ output namely the MPD file        116 ₁ and the adaptive bit rate segments 118 ₁ are received by        the content management system 100′. Note: The MPD file 116 ₁ and        the adaptive bit rate segments 118 ₁ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₁.    -   3. The MPEG-DASH transcoder 114 ₂ provides the MPD file 116 ₂        and the adaptive bit rate segments 118 ₂ for the master content        file 120 ₂.    -   4. The MPEG-DASH transcoder's 114 ₂ output namely the MPD file        116 ₂ and

the adaptive bit rate segments 118 ₂ are received by the contentmanagement system 100′. Note: The MPD file 116 ₂ and the adaptive bitrate segments 118 ₂ can be received from any other device as wellinstead of the MPEG-DASH transcoder 114 ₂.

-   -   5. The MPEG-DASH transcoder 114 ₃ provides the MPD file 116 ₃        and the adaptive bit rate segments 118 ₃ for the master content        file 120 ₃.    -   6. The MPEG-DASH transcoder's 114 ₃ output namely the MPD file        116 ₃ and the adaptive bit rate segments 118 ₃ are received by        the content management system 100′. Note: The MPD file 116 ₃ and        the adaptive bit rate segments 118 ₃ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₃.    -   7. The MPEG-DASH transcoder 114 ₄ provides the MPD file 116 ₄        and the adaptive bit rate segments 118 ₄ for the master content        file 120 ₄.    -   8. The MPEG-DASH transcoder's 114 ₄ output namely the MPD file        116 ₄ and the adaptive bit rate segments 118 ₄ are received by        the content management system 100′. Note: The MPD file 116 ₄ and        the adaptive bit rate segments 118 ₄ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₄.    -   9. The user 146 creates rules 144 which provide details on how        to create the multiple versions of MPD files 142 ₁, 142 ₂ . . .        142 _(n). The rules 144 can be and not limited to, based on        timing information, metadata, user profiles, content ratings,        regional and demographic information etc.    -   10. The processor 106-memory 108 (e.g., rules engine) uses the        rules 144, the MPD files 116 ₁, 116 ₂, 116 ₃, 116 ₄ and the        adaptive bit rate segments 118 ₁, 118 ₂, 118 ₃, 118 ₄ to create        the multiple versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n).        -   A. An example is discussed next to help explain several ways            that the processor 106-memory 108 (e.g., rules engine) can            use the rules 144 plus the master MPD file 116 ₁ (movie            content) and the master MPD file 116 ₂ (advertisement            content) to create MPD file 142 ₁. The final output MPD file            142 ₁ can be a combination of these two master MPD files 116            ₁ and 116 ₂ in a specific certain order. In this example,            FIG. 4B illustrates a portion of the MPD file 116 ₁ (e.g.,            master MPD file 1 116 ₁) which has a media presentation 122            with multiple periods 124 ₁, 124 ₂, 124 ₃, 124 ₄ and the            first period 124 ₁ includes adaptation sets 128 ₁, 128 ₂,            128 ₃, 128 ₄. FIG. 4C illustrates a portion of the MPD file            2 116 ₂ (e.g., master MPD file 2 116 ₂) which has an            advertisement presentation 122 with multiple periods 124 ₁            and 124 ₂ and the first period 124 ₁ includes adaptation            sets 128 ₁, 128 ₂, 128 ₃, 128 ₄. FIG. 4D illustrates a            portion of the “version 1” MPD file 142 ₁ which was created            by the processor 106-memory 108 (e.g., rules engine) when            using the rule 144 which is set to add the advertisement            presentation 122 of master MPD file 2 116 ₂ to master MPD            file 1 116 ₁ and to recode the time in the newly created            “version 1” MPD file 142 ₁. The “version 1” MPD file 142 ₁            includes a media presentation 122 with periods 124 ₁ and 124            ₂ (which contain the advertisement presentation 122 of            master MPD file 2 116 ₂) and periods 124 ₃, 124 ₄, 124 ₅,            and 124 ₅ (which contain the media presentation 122 of            master MPD file 1 116 ₁ but with recoded times). It should            be noted that the advertisement presentation 122 of master            MPD file 2 116 ₂ can be added at any place in the master MPD            file 1 116 ₁ to create “version 1” MPD file 142 ₁.        -   B. An example is discussed next to help explain several ways            that the processor 106-memory 108 (e.g., rules engine) can            use the rules 144 plus the master MPD file 116 ₁ (movie            content) and the master MPD file 116 ₃ (advertisement            content) to create MPD file 142 ₂. The final output MPD file            142 ₂ can be a combination of these two master MPD files 116            ₁ and 116 ₃ in a specific certain order. In this example,            FIG. 4B illustrates a portion of the MPD file 116 ₁ (e.g.,            master MPD file 1 116 ₁) which has a media presentation 122            with multiple periods 124 ₁, 124 ₂, 124 ₃, 124 ₄ and the            first period 124 ₁ includes adaptation sets 128 ₁, 128 ₂,            128 ₃, 128 ₄. FIG. 4E illustrates a portion of the MPD file            3 116 ₃ (e.g., master MPD file 3 116 ₃) which has an            advertisement presentation 122 with multiple periods 124 ₁            and 124 ₂ and the first period 124 ₁ includes adaptation            sets 128 ₁, 128 ₂, 128 ₃, 128 ₄. FIG. 4F illustrates a            portion of the “version 2” MPD file 142 ₂ which was created            by the processor 106-memory 108 (e.g., rules engine) when            using the rule 144 which is set to add the advertisement            presentation 122 of master MPD file 3 116 ₃ to master MPD            file 1 116 ₁ and to recode the time in the newly created            “version 2” MPD file 142 ₂. The “version 2” MPD file 142 ₂            includes a media presentation 122 with periods 124 ₁ and 124            ₂ (which contain the advertisement presentation 122 of            master MPD file 3 116 ₃) and periods 124 ₃, 124 ₄, 124 ₅,            and 124 ₆ (which contain the media presentation 122 of            master MPD file 1 116 ₁ but with recoded times). It should            be noted that the advertisement presentation 122 of master            MPD file 3 116 ₃ can be added at any place in the master MPD            file 1 116 ₁ to create “version 2” MPD file 142 ₂.        -   Note: The same logic associated with examples A and B can be            applied to combine multiple movie contents and not just one            movie content and advertising content.        -   C. An example is discussed next to help explain several ways            that the processor 106-memory 108 (e.g., rules engine) can            use the rules 144 plus the master MPD file 116 ₁ (movie            content) and the master MPD file 116 ₄ (audio content) to            create MPD file 142 ₃. The final output MPD file 142 ₃ is a            combination of these two master MPD files 116 ₁ and 116 ₄.            In this example, FIG. 4B illustrates a portion of the MPD            file 116 ₁ (e.g., master MPD file 1 116 ₁) which has a media            presentation 122 with multiple periods 124 ₁, 124 ₂, 124 ₃,            124 ₄ and the first period 124 ₁ includes adaptation sets            128 ₁, 128 ₂, 128 ₃, 128 ₄. FIG. 4G illustrates a portion of            the MPD file 4 116 ₄ (e.g., master MPD file 4 116 ₄) which            has a media presentation 122 with multiple periods 124 ₁,            124 ₂, 124 ₃, 124 ₄ and the first period 124 ₁ includes            adaptation set 128 ₁. FIG. 4H illustrates a portion of the            “version 3” MPD file 142 ₃ which was created by the            processor 106-memory 108 (e.g., rules engine) when using the            rule 144 which is set to add the media presentation 122 of            master MPD file 4 116 ₄ to master MPD file 1 116 ₁. The            “version 3” MPD file 142 ₃ includes a media presentation 122            with multiple periods 124 ₁, 124 ₂, 124 ₃, 124 ₄ and the            first period 124 ₁ includes adaptation sets 128 ₁, 128 ₂,            128 ₃, 128 ₄, 128 ₅ (where adaptation set 128 ₅ includes the            audio track from master MPD file 4 116 ₄—the other periods            124 ₂, 124 ₃, 124 ₄ would also have adaptation sets which            include the audio track from master MPD file 4 116 ₄).    -   11. The processor 106-memory 108 then distributes the different        versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n) to        corresponding downstream systems 148 ₁, 148 ₂ . . . 148 _(n)        (e.g., content delivery networks 148 ₁, 148 ₂ . . . 148 _(n))        based on requirements.

Note 1: In FIG. 4A, versioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) arepresented as output of the processor 106-memory 108 (e.g., rule engine).In this case, the processor 106-memory 108 (e.g., rule engine)dynamically generates the versioned MPD files 142 ₁, 142 ₂ . . . 142_(n) on the fly and distributes them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n). Alternatively, the processor106-memory 108 (e.g., rule engine) can generate and store (cache) theversioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) in the database 111 andthen at some later time distribute them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n).

Note 2: The exemplary system 100′ may include many other well knowncomponents but for clarity those well known components are not describedherein while the components 104, 106, 108, 111 and 112 which arerelevant to the invention have been described.

Note 3: The use case #2 included an example utilizing the DASH standardbut it should be appreciated that the present invention is not limitedto the DASH standard but could utilize other adaptive streamingtechnologies such as HLS by Apple, Smooth Streaming by Microsoft, or HDSby Adobe.

Referring to FIG. 5, there is a diagram an exemplary content deliverysystem 100″ which is used to explain a use case #3 in accordance with anembodiment of the present invention. As shown, the content deliverysystem 100″ includes the input interface 104, the processor 106, thememory 108, the database 111, and the output interface 112. In thisparticular example, the system's input interface 104 is showninterfacing with one remote transcoder 114 ₁ and receiving therefrom onesource descriptor file 116 ₁ (MPD file 116 ₁) and the associatedadaptive bit rate segments 118 ₁. The remote transcoder 114 ₁ receivesthe master content file 120 ₁ and produces the corresponding sourcedescriptor file 116 ₁ and the associated adaptive bit rate segments 118₁. The basic steps associated with the use case #3 are as follows:

-   -   1. The MPEG-DASH transcoder 114 ₁ provides the MPD file 116 ₁        and the adaptive bit rate segments 118 ₁ for the master content        file 120 ₁.    -   2. The MPEG-DASH transcoder's 114 ₁ output namely the MPD file        116 ₁ and the adaptive bit rate segments 118 ₁ are received by        the content delivery system 100″. Note: The MPD file 116 ₁ and        the adaptive bit rate segments 118 ₁ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₁.    -   3. The user 146 creates rules 144 which provide details on how        to create the multiple versions of MPD files 142 ₁, 142 ₂ . . .        142 _(n). The rules 144 can be and not limited to, based on        timing information, metadata, user profiles, content ratings,        regional and demographic information etc.    -   4. The processor 106-memory 108 (e.g., rules engine) uses the        rules 144, the MPD file 116 ₁ and the adaptive bit rate segments        118 ₁ to create the multiple versions of MPD files 142 ₁, 142 ₂        . . . 142 _(n). The examples described above with respect to        FIGS. 3B-3D can also be performed by the content delivery system        100″ in use case #3 as well.    -   5. The processor 106-memory 108 then distributes the different        versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n) to        corresponding downstream systems 148 ₁, 148 ₂ . . . 148 _(n)        (e.g., individual users 148 ₁, 148 ₂ . . . 148 _(n)) based on        requirements. For instance, when anyone of the individual users        148 ₁, 148 ₂ . . . 148 _(n) sends a request for a particular        content, the processor 106-memory 108 can utilize a resolving        mechanism 145 along with different types of user information to        determine the specific version of the MPD file 142 ₁, 142 ₂ . .        . 142 _(n) which needs to be sent to that particular individual        user 148 ₁.        -   The resolving mechanism 145 can utilize various implicit and            explicit inputs collected from the device associated with            the individual user 148 ₁. For instance, these inputs can            include user's location (implicit), the user's customer            profile information (age, sex), the user's previous history            and explicit information such as the user's preference,            occupation, personal interest etc. For resolving to select            the proper MPD file 142 ₁, 142 ₂ . . . 142 _(n) which            includes certain segments or not, the resolving mechanism            145 can use rules which can be defined such as:        -   A. If country==‘China’, then the resolving mechanism 145            selects a MPD file 142 ₁, 142 ₂ . . . 142 _(n) which does            not include time codes 00:1:30 to 00:2:15 since the video            associated with these time-codes contain dialogue which            needs to be censored due to government regulations.        -   B. If age>=18 and preference==‘No Violence’, then the            resolving mechanism 145 selects a MPD file 142 ₁, 142 ₂ . .            . 142 _(n) which does not include time codes 00:05:30 to            00:05:45 etc since the video associated with these            time-codes contains “violent” subject matter.        -   Note: These time codes and rule information can be collected            in any content delivery system or in a steam server itself.            The rules mentioned above may not be limited to those            options and formats. In fact, the rules can be collected in            Extensible Markup Language (XML) format or any proprietary            format and various types of operators can provide rules to            enrich the resolving mechanism 145. If desired, the content            management system 100′ may also utilize a resolving            mechanism 145 to determine which MPD file(s) 142 ₁, 142 ₂ .            . . 142 _(n) to distribute to downstream systems 148 ₁, 148            ₂ . . . 148 _(n) (e.g., content delivery systems).

Note 1: In FIG. 5, versioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) arepresented as output of the processor 106-memory 108 (e.g., rule engine).In this case, the processor 106-memory 108 (e.g., rule engine)dynamically generates the versioned MPD files 142 ₁, 142 ₂ . . . 142_(n) on the fly and distributes them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n) Alternatively, the processor106-memory 108 (e.g., rule engine) can generate and store (cache) theversioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) in the database 111 andthen at some later time distribute them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n).

Note 2: The exemplary system 100″ may include many other well knowncomponents but for clarity those well known components are not describedherein while the components 104, 106, 108, 111 and 112 which arerelevant to the invention have been described.

Note 3: The use case #3 included an example utilizing the DASH standardbut it should be appreciated that the present invention is not limitedto the DASH standard but could utilize other adaptive streamingtechnologies such as HLS by Apple, Smooth Streaming by Microsoft, or HDSby Adobe.

Referring to FIGS. 6A-6B, there are diagrams of an exemplary contentdelivery system 100″ which is used to explain a use case #3 inaccordance with an embodiment of the present invention. As shown, theexemplary content delivery system 100″ includes the input interface 104,the processor 106, the memory 108, the database 111, and the outputinterface 112. In this particular example, the system's input interface104 is shown interfacing with four remote transcoders 114 ₁, 114 ₂, 114₃, 114 ₄ and respectively receiving therefrom three source descriptorfiles 116 ₁, 116 ₂, 116 ₃, 116 ₄ (e.g., MPD files) and their associatedadaptive bit rate segments 118 ₁, 118 ₂, 118 ₃, 118 ₄. As shown, theremote transcoders 114 ₁, 114 ₂, 114 ₃, 114 ₄ respectively receive themaster content files 120 ₁, 120 ₂, 120 ₃, 120 ₄ and produce thecorresponding source descriptor files 116 ₁, 116 ₂, 116 ₃, 116 ₄ andtheir associated adaptive bit rate segments 118 ₁, 118 ₂, 118 ₃, 118 ₄.The basic steps associated with the use case #4 are as follows:

-   -   1. The MPEG-DASH transcoder 114 ₁ provides the MPD file 116 ₁        and the adaptive bit rate segments 118 ₁ for the master content        file 120 ₁.    -   2. The MPEG-DASH transcoder's 114 ₁ output namely the MPD file        116 ₁ and the adaptive bit rate segments 118 ₁ are received by        the content management system 100′. Note: The MPD file 116 ₁ and        the adaptive bit rate segments 118 ₁ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₁.    -   3. The MPEG-DASH transcoder 114 ₂ provides the MPD file 116 ₂        and the adaptive bit rate segments 118 ₂ for the master content        file 120 ₂.    -   4. The MPEG-DASH transcoder's 114 ₂ output namely the MPD file        116 ₂ and the adaptive bit rate segments 118 ₂ are received by        the content management system 100′. Note: The MPD file 116 ₂ and        the adaptive bit rate segments 118 ₂ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₂.    -   5. The MPEG-DASH transcoder 114 ₃ provides the MPD file 116 ₃        and the adaptive bit rate segments 118 ₃ for the master content        file 120 ₃.    -   6. The MPEG-DASH transcoder's 114 ₃ output namely the MPD file        116 ₃ and the adaptive bit rate segments 118 ₃ are received by        the content management system 100′. Note: The MPD file 116 ₃ and        the adaptive bit rate segments 118 ₃ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₃.    -   7. The MPEG-DASH transcoder 114 ₄ provides the MPD file 116 ₄        and the adaptive bit rate segments 118 ₄ for the master content        file 120 ₄.    -   8. The MPEG-DASH transcoder's 114 ₄ output namely the MPD file        116 ₄ and the adaptive bit rate segments 118 ₄ are received by        the content management system 100′. Note: The MPD file 116 ₄ and        the adaptive bit rate segments 118 ₄ can be received from any        other device as well instead of the MPEG-DASH transcoder 114 ₄.    -   9. The user 146 creates rules 144 which provide details on how        to create the multiple versions of MPD files 142 ₁, 142 ₂ . . .        142 _(n). The rules 144 can be and not limited to, based on        timing information, metadata, user profiles, content ratings,        regional and demographic information etc.    -   10. The processor 106-memory 108 (e.g., rules engine) uses the        rules 144, the MPD file 116 ₁ and the adaptive bit rate segments        118 ₁ to create the multiple versions of MPD files 142 ₁, 142 ₂        . . . 142 _(n). The examples described above with respect to        FIGS. 4B-4H can also be performed by the content delivery system        100″ in use case #4 as well.    -   11. The processor 106-memory 108 then distributes the different        versions of MPD files 142 ₁, 142 ₂ . . . 142 _(n) to        corresponding downstream systems 148 ₁, 148 ₂ . . . 148 _(n)        (e.g., individual users 148 ₁, 148 ₂ . . . 148 _(n)) based on        requirements. For instance, when anyone of the individual users        148 ₁, 148 ₂ . . . 148 _(n) sends a request for a particular        content, the processor 106-memory 108 can utilize a resolving        mechanism 145 along with different types of user information to        determine the specific version of the MPD file 142 ₁, 142 ₂ . .        . 142 _(n) which needs to be sent to that particular individual        user 148 ₁.        -   The resolving mechanism 145 can utilize various implicit and            explicit inputs collected from the device associated with            the individual user 148 ₁. For instance, these inputs can            include user's location (implicit), the user's customer            profile information (age, sex), the user's previous history            and explicit information such as the user's preference,            occupation, personal interest etc. For resolving to select            the proper MPD file 142 ₁, 142 ₂ . . . 142 _(n) which            includes certain segments or not, the resolving mechanism            145 can use rules which can be defined such as:        -   A. If country==‘China’, then the resolving mechanism 145            selects a MPD file 142 ₁, 142 ₂ . . . 142 _(n) which does            not include time codes 00:1:30 to 00:2:15 since the video            associated with these time-codes contain dialogue which            needs to be censored due to government regulations.        -   B. If age>=18 and preference==‘No Violence’, then the            resolving mechanism 145 selects a MPD file 142 ₁, 142 ₂ . .            . 142 _(n) which does not include time codes 00:05:30 to            00:05:45 etc since the video associated with these            time-codes contains “violent” subject matter.        -   Note: These time codes and rule information can be collected            in any content delivery system or in a steam server itself.            The rules mentioned above may not be limited to those            options and formats. In fact, the rules can be collected in            Extensible Markup Language (XML) format or any proprietary            format and various types of operators can provide rules to            enrich the resolving mechanism 145. If desired, the content            management system 100′ may also utilize a resolving            mechanism 145 to determine which MPD file(s) 142 ₁, 142 ₂ .            . . 142 _(n) to distribute to downstream systems 148 ₁, 148            ₂ . . . 148 _(n) (e.g., content delivery systems).

Note 1: In FIG. 6, versioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) arepresented as output of the processor 106-memory 108 (e.g., rule engine).In this case, the processor 106-memory 108 (e.g., rule engine)dynamically generates the versioned MPD files 142 ₁, 142 ₂ . . . 142_(n) on the fly and distributes them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n). Alternatively, the processor106-memory 108 (e.g., rule engine) can generate and store (cache) theversioned MPD files 142 ₁, 142 ₂ . . . 142 _(n) in the database 111 andthen at some later time distribute them to the corresponding downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n).

Note 2: The exemplary system 100″ may include many other well knowncomponents but for clarity those well known components are not describedherein while the components 104, 106, 108, 111 and 112 which arerelevant to the invention have been described.

Note 3: The use case #4 included an example utilizing the DASH standardbut it should be appreciated that the present invention is not limitedto the DASH standard but could utilize other adaptive streamingtechnologies such as HLS by Apple, Smooth Streaming by Microsoft, or HDSby Adobe.

From the foregoing, one skilled in the art with the teaching herein willreadily appreciate that the system 100, 100′ and 100″ and method 200 areconfigured receiving one or more source descriptor files 116 ₁, 116 ₂ .. . 116 _(n) (e.g., MPD files, HLS m3u8 files, HTTP manifest files)along with their associated adaptive bit rate segments 118 ₁, 118 ₂ . .. 118 _(n). The system 100, 100′ and 100″ and method 200 are alsoconfigured for receiving rules 144 (e.g., content ratings, timinginformation, user profiles, regional and demographic information) andthen creating multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n)based on the received rules 144 and the one or more source descriptorfiles 116 ₁, 116 ₂ . . . 116 _(n) The system 100, 100′ and 100″ andmethod 200 are further configured for distributing the multipledescriptor files 142 ₁, 142 ₂ . . . 142 _(n) to one or more downstreamsystems 148 ₁, 148 ₂ . . . 148 _(n) (e.g., content delivery systems,users). This is all possible in part because with adaptive streamingtechnology, the content files 120 ₁, 120 ₂ . . . 120 _(n) are split intomultiple segments which are linked together by their respective sourcedescriptor files 116 ₁, 116 ₂ . . . 116 _(n). The system 100, 100′ and100′ can take these descriptor files 116 ₁, 116 ₂ . . . 116 _(n) anddynamically generate based on certain rules 144 (to add/remove segments)multiple descriptor files 142 ₁, 142 ₂ . . . 142 _(n). For instance,since MPEG-DASH supports playing multiple tracks this means that thesystem 100, 100′ and 100″ can combine a video track from one set ofsegments in one source descriptor file 116 ₁ and audio tracks fromanother set of segments in another source descriptor file 116 ₂ tocreate descriptor file 142 ₁. This is possible because per MPEG-DASH thesegments are provided with HTTP URLs so the system 100, 100′ and 100″can provide link contents from different sources and dynamicallygenerate versions of contents. This can be done during the contentpreparation using a content management system or in content deliverynetwork's cache servers.

The system 100, 100′ and 100″ is a marked-improvement over the prior artsince it can avoid having to create multiple versions of a content fileby taking one content file and creating multiple versions of thedescriptor file. In this way, maintenance will be reduced and also thestorage requirements will be reduced. The system 100, 100′ and 100″ candynamically create multiple versions of descriptor files 142 ₁, 142 ₂ .. . 142 _(n) and all that is need is to maintain rules 144 whichindicate when to include or exclude contents by time codes. Additionallythe time to create new versions will be reduced significantly and thesavings would be substantial when the content needs to be supported inmultiple devices in multiple formats for adaptive steaming. Thefollowing are some additional advantages associated with the presentinvention:

-   -   The segments from one source descriptor file 116 ₁ can be        removed and/or added based on rules 144.    -   The segments from multiple master files 116 ₁, 116 ₂ . . . 116        _(n) can be combined together to create new version descriptor        files 142 ₁, 142 ₂ . . . 142 _(n).    -   The individual tracks from one source descriptor file 116 ₁ can        be modified if needed: such as adding and/or removing particular        audio tracks.    -   The new versions of descriptor files 142 ₁, 142 ₂ . . . 142 _(n)        can be created during distribution to the end users 148 ₁, 148 ₂        . . . 148 _(n) or during content preparation time by both. This        provides flexibility for the operators to define various        versions of descriptor files 142 ₁, 142 ₂ . . . 142 _(n) at any        time without adding content processing (transcoding, quality        check etc) overhead and storage overhead.    -   If the versions of descriptor files 142 ₁, 142 ₂ . . . 142 _(n)        are created in the content management system 100′, then various        versions can be stored as rule information as opposed to        individual media files for audit purposes.    -   The multiple copies of same content file need not be stored for        version purpose and hence less storage will be needed and it        will be easier to manage.    -   Multiple versions descriptor files 142 ₁, 142 ₂ . . . 142 _(n)        are created with a single master source file 116 ₁ (for        example). So it reduces time and effort to create versions and        simplifies business process.    -   The versions of descriptor files 142 ₁, 142 ₂ . . . 142 _(n) are        created dynamically based on rules 144. So it is easier to        create new versions of descriptor files 142 ₁, 142 ₂ . . . 142        _(n).    -   The service can be personalized based on user information thus        providing better user experience.

Although multiple embodiments of the present invention have beenillustrated in the accompanying Drawings and described in the foregoingDetailed Description, it should be understood that the invention is notlimited to the disclosed embodiments, but instead is also capable ofnumerous rearrangements, modifications and substitutions withoutdeparting from the present invention that as has been set forth anddefined within the following claims.

1. A system configured for creating multiple descriptor files, thesystem comprising: a processor; and a memory that storesprocessor-executable instructions therein where the processor interfaceswith the memory and executes the processor-executable instructions toenable the following operations: receiving one or more source descriptorfiles and associated adaptive bit rate segments for one or more mastercontent files; receiving rules which provide details on how the multipledescriptor files are to be created; creating the multiple descriptorfiles based on the rules and the one and more source descriptor files;and distributing one or more of the multiple descriptor files to one ormore downstream systems.
 2. The system of claim 1, wherein the receivedone or more source descriptor files further comprises: one or moreHypertext Transfer Protocol (HTTP) Live Stream (HLS) m3u8 files; one ormore Hypertext Transfer Protocol (HTTP) manifest files; or one or moremedia presentation description (MPD) files.
 3. The system of claim 1,wherein the rules include one or more of the following: content ratings;language information; timing information; metadata; user profiles; andregional and demographic information.
 4. The system of claim 1, whereinthe processor executes the processor-executable instructions toimplement the creating operation by dynamically creating the multipledescriptor files while the multiple descriptor files are beingdistributed to the one or more downstream systems.
 5. The system ofclaim 1, wherein the processor executes the processor-executableinstructions to implement the creating operation by creating themultiple descriptor files and storing the multiple descriptor filesbefore the multiple descriptor files are being distributed to the one ormore downstream systems.
 6. The system of claim 1, wherein the processorexecutes the processor-executable instructions to implement the creatingoperation by manipulating at least one of the one or more sourcedescriptor files based on the rules without transcoding the one or moresource descriptor files to an adaptive stream format and withoutgenerating new content files to create the multiple descriptor files. 7.The system of claim 6, wherein the processor executes theprocessor-executable instructions to implement the manipulatingoperation by removing at least one period including a video track and anaudio track from one of the one or more source descriptor files andrecoding time information within the one of the one or more sourcedescriptor files to create one of the multiple descriptor files.
 8. Thesystem of claim 6, wherein the processor executes theprocessor-executable instructions to implement the manipulatingoperation by removing an audio track from one of the one or more sourcedescriptor files to create one of the multiple descriptor files.
 9. Thesystem of claim 6, wherein the processor executes theprocessor-executable instructions to implement the manipulatingoperation by adding advertisements from one or more of the sourcedescriptor files to another one of the source descriptor files to createone of the multiple descriptor files.
 10. The system of claim 6, whereinthe processor executes the processor-executable instructions toimplement the manipulating operation by adding one or more periods eachincluding a video track and an audio track from one of the one or moresource descriptor files to one of the other source files to create oneof the multiple descriptor files.
 11. The system of claim 6, wherein theprocessor executes the processor-executable instructions to implementthe manipulating operation by adding one or more audio tracks from oneof the one or more source descriptor files to one of the other sourcefiles to create one of the multiple descriptor files.
 12. The system ofclaim 1, wherein the processor executes the processor-executableinstructions to implement the distributing operation by resolving whichone of the multiple descriptor files to send to each of the downstreamsystems.
 13. The system of claim 1, wherein the system is a contentmanagement system 100′ and the downstream systems are content deliverynetworks.
 14. The system of claim 1, wherein the system is a contentdelivery network 100″ and the downstream systems are individual users.15. A method for creating multiple descriptor files, the methodimplemented by a system comprising the steps of: receiving one or moresource descriptor files and associated adaptive bit rate segments forone or more master content files; receiving rules which provide detailson how the multiple descriptor files are to be created; creating themultiple descriptor files based on the rules and the one and more sourcedescriptor files; and distributing one or more of the multipledescriptor files to one or more downstream systems.
 16. The method ofclaim 15, wherein the received one or more source descriptor filesfurther comprises: one or more Hypertext Transfer Protocol (HTTP) LiveStream (HLS) m3u8 files; one or more Hypertext Transfer Protocol (HTTP)manifest files; or one or more media presentation description (MPD)files.
 17. The method of claim 15, wherein the rules include one or moreof the following: content ratings; language information; timinginformation; metadata; user profiles; and regional and demographicinformation.
 18. The method of claim 15, wherein the creating stepfurther comprises dynamically creating the multiple descriptor fileswhile the multiple descriptor files are being distributed to the one ormore downstream systems.
 19. The method of claim 15, wherein thecreating step further comprises creating the multiple descriptor filesand storing the multiple descriptor files before the multiple descriptorfiles are being distributed to the one or more downstream systems. 20.The method of claim 15, wherein the creating step further comprises astep of manipulating at least one of the one or more source descriptorfiles based on the rules without transcoding the one or more sourcedescriptor files to an adaptive stream format and without generating newcontent files to create the multiple descriptor files.
 21. The method ofclaim 20, wherein the manipulating step further comprises steps ofremoving at least one period including a video track and an audio trackfrom one of the one or more source descriptor files and recoding timeinformation within the one of the one or more source descriptor files tocreate one of the multiple descriptor files.
 22. The method of claim 20,wherein the manipulating step further comprises a step of removing anaudio track from one of the one or more source descriptor files tocreate one of the multiple descriptor files.
 23. The method of claim 20,wherein the manipulating step further comprises a step of addingadvertisements from one or more of the source descriptor files toanother one of the source descriptor files to create one of the multipledescriptor files.
 24. The method of claim 20, wherein the manipulatingstep further comprises a step of adding one or more periods eachincluding a video track and an audio track from one of the one or moresource descriptor files to one of the other source files to create oneof the multiple descriptor files.
 25. The method of claim 20, whereinthe manipulating step further comprises a step of adding one or moreaudio tracks from one of the one or more source descriptor files to oneof the other source files to create one of the multiple descriptorfiles.
 26. The method of claim 15, wherein the distributing step furthercomprises a step of resolving which one of the multiple descriptor filesto send to each of the downstream systems.
 27. The method of claim 15,wherein the system is a content management system and the downstreamsystems are content delivery networks.
 28. The method of claim 15,wherein the system is a content delivery network and the downstreamsystems are individual users.